延續昨天的主題，今天要測試的是進階版的節點指派方式。昨天測試的是針對節點標籤作節點佈署時的選擇依據，如果沒有符合標籤的節點服務就沒辦法佈署上去，今天要說的方式能對節點標籤的選擇有更多的限制條件。
更多的限制條件又可分為HardMode跟SoftMode兩種。簡單來說HardMode就是一定要有完全符合條件的節點服務才會佈署上去，否則便無法成功佈署；反之SoftMode是將節點條件作為佈署到節點時的選擇參考，會依照符合上面節點的條件優先佈署到該節點上面，如果沒有符合條件的節點就按照積分順序高低作挑選。今天我們用到的是HardMode。

參數說明

底下是我們用到的YAML檔，接著對參數部分作對照:

# hard-nodeaffinity.yaml
apiVersion: v1
kind: Pod
metadata:
  name: hard-nodeaffinity
  labels:
    app: hard-nodeaff
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: status
            operator: In
            values:
            - ok
  containers:
  - name: nginx
    image: nginx:stable
    ports:
    - containerPort: 80

在YAML檔中的spec底下可以看到多出了一個affinity的欄位:

• affinity
  親和性設定
• nodeAffinity
  節點親和性
• requiredDuringSchedulingIgnoredDuringExecution
  顧名思義是指這些規則生效的時間點在服務佈署當下生效，如果之後節點上標籤有所變動也不會影響到服務的佈署。舉例來說服務A佈署時因為節點B有OK這個標籤而被佈署到B節點上，假設佈署後把B節點的OK標籤移除掉，A服務仍然會維持在節點上面運行，不會受到節點標籤改變而影響(因為規則的生效時間已過)。
• nodeSelectorTerms
  設定規則
• matchExpressions
  設定配對條件，可以同時有多組配對條件存在

在配對條件中透過類似表達式的方式去設定條件:

• key
  相當於節點標籤(label，label=)
• value
  相當於節點標籤的健值(label=之中的name)
• operator
  邏輯判斷符號，效果如下表1所示

表1 親和性中的邏輯判斷符號與效果

佈署

接著在佈署之前，我們先加上節點標籤

kubectl label nodes k8s-node02 status=ok

kubectl apply -f hard-nodeaffinity.yaml
kubectl get pods -o wide

可以看到服務確實佈署在k8s-node02節點上。
現在我們移除節點標籤:

kubectl label nodes k8s-node02 status-
kubectl get nodes --show-labels

可以看到節點標籤中的status標籤已經被移除，接著檢查一下剛剛佈署上去的服務狀態:

kubectl get pods -o wide

可以看到服務仍然正常運行在節點上，如同前面所提到的，規則只生效於佈署服務的當下，佈署後節點標籤的變動並不會對服務造成影響。

接著我們改佈署到KubeEdge的節點上試試，由於我們剛剛已經將status標籤從Kubernetes節點中移除，所以我們現在將標籤加在KubeEdge節點上:

kubectl label nodes edge status=ok
kubectl apply -f  hard-nodeaffinity.yaml
kubectl get pods -o wide

為了驗證一下HardMode的特性，我們把status標籤從節點中移除掉:

kubectl label node edge status-

將剛剛佈署上去的服務移除後再從新佈署一次:

kubectl delete pods hard-nodeaffinity
kubectl apply -f hard-nodeaffinity.yaml

可以看到由於沒有符合條件的節點，所以服務無法成功佈署。